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Abstract 


This document provides guidance to designers of Authentication, 
Authorization, and Accounting (AAA) key management protocols. The 
guidance is also useful to designers of systems and solutions that 
include AAA key management protocols. Given the complexity and 
difficulty in designing secure, long-lasting key management 
algorithms and protocols by experts in the field, it is almost 
certainly inappropriate for IETF working groups without deep 
expertise in the area to be designing their own key management 
algorithms and protocols based on Authentication, Authorization, and 
Accounting (AAA) protocols. The guidelines in this document apply to 
documents requesting publication as IETF RFCs. Further, these 
guidelines will be useful to other standards development 
organizations (SDOs) that specify AAA key management. 
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1. Introduction 


This document provides architectural guidance to designers of AAA key 
management protocols. The guidance is also useful to designers of 
systems and solutions that include AAA key management protocols. 


AAA key management often includes a collection of protocols, one of 
which is the AAA protocol. Other protocols are used in conjunction 
with the AAA protocol to provide an overall solution. These other 
protocols often provide authentication and security association 
establishment. 


Given the complexity and difficulty in designing secure, long-lasting 
key management algorithms and protocols by experts in the field, it 
is almost certainly inappropriate for IETF working groups without 
deep expertise in the area to be designing their own key management 
algorithms and protocols based on Authentication, Authorization and 
Accounting (AAA) protocols. These guidelines apply to documents 
requesting publication as IETF RFCs. Further, these guidelines will 
be useful to other standards development organizations (SDOs) that 
specify AAA key management that depends on IETF specifications for 
protocols such as Extensible Authentication Protocol (EAP) [RFC3748], 
Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and 
Diameter [RFC3588]. 


In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley 
gave a presentation on "Key Management in AAA" [H]. That 
presentation established the vast majority of the requirements 
contained in this document. Over the last three years, this 
collection of requirements have become known as the "Housley 
Criteria". 
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1.1. Requirements Specification 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in RFC 2119 [RFC2119]. 


An AAA key management proposal is not compliant with this 
specification if it fails to satisfy one or more of the MUST or MUST 
NOT statements. An AAA key management proposal that satisfies all 
the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be 
"unconditionally compliant"; one that satisfies all the MUST and MUST 
NOT statements but not all the SHOULD or SHOULD NOT requirements is 
said to be "conditionally compliant". 


1.2. Mandatory to Implement 


The guidance provided in this document is mandatory to implement. 
However, it is not mandatory to use. That is, configuration at the 
time of deployment may result in a deployed implementation that does 
not conform with all of these requirements. 


For example, [RFC4072] enables EAP keying material to be delivered 
from a AAA server to an AAA client without disclosure to third 


parties. Thus, key confidentiality is mandatory to implement in 
Diameter [RFC3588]. However, key confidentiality is not mandatory to 
use. 


1.3. Terminology 
This section defines terms that are used in this document. 


AAA 
Authentication, Authorization, and Accounting (AAA). AAA 
protocols include RADIUS [RFC2865] and Diameter [RFC3588]. 


Authenticator 
The party initiating EAP authentication. The term 
authenticator is used in [802.1X], and authenticator has the 
same meaning in this document. 


Backend authentication server 
A backend authentication server is an entity that provides an 
authentication service to an authenticator. This terminology 
is also used in [802.1X]. 
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CHAP 
Challenge Handshake Authentication Protocol; a one-way 
challenge/response authentication protocol defined in 
[RFC1994]. 


EAP 
Extensible Authentication Protocol, defined in [RFC3748]. 


EAP server 
The entity that terminates the EAP authentication method with 
the peer. In the case where no backend authentication server 
is used, the EAP server is part of the authenticator. In the 
case where the authenticator operates in pass-through mode, the 
EAP server is located on the backend authentication server. 


Key Wrap 
The encryption of one symmetric cryptographic key in another. 
The algorithm used for the encryption is called a key wrap 
algorithm or a key encryption algorithm. The key used in the 
encryption process is called a key-encryption key (KEK). 


PAP 
Password Authentication Protocol; a deprecated cleartext 
password PPP authentication protocol, originally defined in 
[RFC1334]. 


Party 
A party is a processing entity that can be identified as a 
single role in a protocol. 


Peer 
The end of the link that responds to the authenticator. In 
[802.1X], this end is known as the supplicant. 


PPP 
Point-to-Point Protocol, defined in [RFC1661], provides support 
for multiprotocol serial datalinks. PPP is the primary IP 
datalink used for dial-in NAS connection service. 


Secure Association Protocol 
A protocol for managing security associations derived from EAP 
and/or AAA exchanges. The protocol establishes a security 
association, which includes symmetric keys and a context for 
the use of the keys. An example of a Secure Association 
Protocol is the 4-way handshake defined within [802.11i]. 
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Session Keys 
Keying material used to protect data exchanged after 
authentication has successfully completed, using the negotiated 
ciphersuite. 


Network Access Server (NAS) 
A device that provides an access service for a user toa 


network. The service may be a network connection, or a value 
added service such as terminal emulation, as described in 
[RFC2881]. 


4-Way Handshake 
A Secure Association Protocol, defined in [802.11i], which 
confirms mutual possession of a Pairwise Master Key by two 
parties and distributes a Group Key. 


2. AAA Environment Concerns 


Examples of serious flaws plague the history of key management 
protocol development, starting with the very first attempt to define 
a key management protocol in the open literature, which was published 
in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the 
fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in 
the original 1978 version, in an area not affected by the 1981/1994 
issue. All of these flaws were blindingly obvious once described, 
yet no one spotted them earlier. Note that the original protocol, if 
it were revised to employ certificates, which of course had yet to be 
invented, was only three messages. Many proposed AAA key management 
schemes are significantly more complicated. 


This bit of history shows that key management protocols are subtle. 
Experts can easily miss a flaw. As a result, peer review by multiple 
experts is essential, especially since many proposed AAA key 
management schemes are significantly more complicated. In addition, 
formal methods can help uncover problems [M]. 


AAA-based key management is being incorporated into standards 
developed by the IETF and other standards development organizations 
(SDOs), such as IEEE 802. However, due to ad hoc development of 
AAA-based key management, AAA-based key distribution schemes have 
poorly understood security properties, even when well-studied 
cryptographic algorithms are employed. More academic research is 
needed to fully understand the security properties of AAA-based key 
management in the diverse protocol environments where it is being 
employed today. In the absence of such research results, pragmatic 
guidance based on sound security engineering principles is needed. 
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In addition to the need for interoperability, cryptographic algorithm 
independent solutions are greatly preferable. Without algorithm 
independence, the AAA-based key management protocol must be changed 
whenever a problem is discovered with any of the selected algorithms. 
As AAA history shows, problems are inevitable. Problems can surface 
due to age or design failure. 


DES [FIPS46] was a well-designed encryption algorithm, and it 
provided protection for many years. Yet, the 56-bit key size was 
eventually overcome by Moore’s Law. No significant cryptographic 
deficiencies have been discovered in DES. 


The history of AAA underlines the importance of algorithm 
independence as flaws have been found in authentication mechanisms 
such as CHAP, MS-CHAPvl [SM1], MS-CHAPv2 [SM2], Kerberos 

[W] [BM] [DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates 
use of the MD5 algorithm for integrity protection, which has known 
deficiencies, and RADIUS has no provisions to negotiate substitute 


algorithms. Similarly, the vendor-specific key wrap mechanism 
defined in [RFC2548] has no provisions to negotiate substitute 
algorithms. 


The principle of least privilege is an important design guideline. 
This principle requires that a party be given no more privilege than 
necessary to perform the task assigned to them. Ensuring least 
privilege requires clear identification of the tasks assigned to each 
party, and explicit determination of the minimum set of privileges 
required to perform those tasks. Only those privileges necessary to 
perform the tasks are granted. By denying to parties unneeded 
privileges, those denied privileges cannot be used to circumvent 
security policy or enable attackers. With this principle in mind, 
AAA key management schemes need to be designed in a manner where each 
party has only the privileges necessary to perform their role. That 
is, no party should have access to any keying material that is not 
needed to perform their own role. A party has access to a particular 
key if it has access to all of the secret information needed to 
derive it. 


EAP is being used in new ways. The inclusion of support for EAP 
within Internet Key Exchange Protocol version 2 (IKEv2) and the 
standardization of robust Wireless LAN security [802.11i] based on 
EAP are two examples. EAP has also been proposed within IEEE 802.16e 
[802.16e] and by the IETF PANA Working Group. AAA-based key 
management is being incorporated into standards developed by the IETF 
and other standards development organizations (SDOs), such as IEEE 
802. However, due to ad hoc development of AAA-based key management, 
AAA-based key distribution schemes have poorly understood security 
properties, even when well-studied cryptographic algorithms are 
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employed. More academic research is needed to fully understand the 
security properties of AAA-based key management in the diverse 
protocol environments where it is being employed today. In the 
absence of research results, pragmatic guidance based on sound 
security engineering principles is needed. 


EAP selects one end-to-end authentication mechanism. The mechanisms 
defined in [RFC3748] only support unilateral authentication, and they 
do not support mutual authentication or key derivation. As a result, 
these mechanisms do not fulfill the security requirements for many 
deployment scenarios, including Wireless LAN authentication 
[RFC4017]. 


To ensure adequate security and interoperability, EAP applications 
need to specify mandatory-to-implement algorithms. As described in 
[RFC3748], EAP methods seeking publication as an IETF RFC need to 
document their security claims. However, some EAP methods are not 
based on well-studied models, which makes the validity of these 
security claims difficult to determine. 


In the context of EAP, the EAP peer and server are the parties 
involved in the EAP method conversation, and they gain access to key 
material when the conversation completes successfully. However, the 
lower-layer needs keying material to provide the desired protection 
through the use of cryptographic mechanisms. As a result, a "pass-— 
through" mode is used to provide the keying material, and the lower- 
layer keying material is replicated from the AAA server to the 
authenticator. The only parties authorized to obtain all of the 
keying material are the EAP peer and server; the authenticator 
obtains only the keying material necessary for its specific role. No 
other party can obtain direct access to any of the keying material; 
however, other parties may receive keys that are derived from this 
keying material for a specific purpose as long as the requirements 
defined in the next section are met. 


3. AAA Key Management Requirements 


The overall goal of AAA key management is to provide cryptographic 
keying material in situations where key derivation cannot be used by 
the peer and authenticator. It may not be possible because the 
authenticator lacks computational power, because it lacks the 
resources necessary to implement the various authentication 
mechanisms that might be required, or because it is undesirable for 
each authenticator to engage in a separate key management 
conversation. 
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This section provides guidance to AAA protocol designers, EAP method 
designers, and security association protocol designers. Acceptable 
solutions MUST meet all of these requirements. 


Cryptographic algorithm independent 


The AAA key management protocol MUST be cryptographic algorithm 
independent. However, an EAP method MAY depend on a specific 
cryptographic algorithm. The ability to negotiate the use of a 
particular cryptographic algorithm provides resilience against 
compromise of a particular cryptographic algorithm. Algorithm 
independence is also REQUIRED with a Secure Association 
Protocol if one is defined. This is usually accomplished by 
including an algorithm identifier and parameters in the 
protocol, and by specifying the algorithm requirements in the 
protocol specification. While highly desirable, the ability to 
negotiate key derivation functions (KDFs) is not required. For 
interoperability, at least one suite of mandatory-to-implement 
algorithms MUST be selected. Note that without protection by 
IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] 
does not meet this requirement, since the integrity protection 
algorithm cannot be negotiated. 


This requirement does not mean that a protocol must support 
both public-key and symmetric-key cryptographic algorithms. It 
means that the protocol needs to be structured in such a way 
that multiple public-key algorithms can be used whenever a 
public-key algorithm is employed. Likewise, it means that the 
protocol needs to be structured in such a way that multiple 
symmetric-key algorithms can be used whenever a symmetric—key 
algorithm is employed. 


Strong, fresh session keys 


While preserving algorithm independence, session keys MUST be 
strong and fresh. Each session deserves an independent session 
key. Fresh keys are required even when a long replay counter 
(that is, one that "will never wrap") is used to ensure that 
loss of state does not cause the same counter value to be used 
more than once with the same session key. 


Some EAP methods are capable of deriving keys of varying 
strength, and these EAP methods MUST permit the generation of 
keys meeting a minimum equivalent key strength. BCP 86 
[RFC3766] offers advice on appropriate key sizes. The National 
Institute for Standards and Technology (NIST) also offers 
advice on appropriate key sizes in [SP800-57]. 
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A fresh cryptographic key is one that is generated specifically 
for the intended use. In this situation, a secure association 
protocol is used to establish session keys. The AAA protocol 
and EAP method MUST ensure that the keying material supplied as 
an input to session key derivation is fresh, and the secure 
association protocol MUST generate a separate session key for 
each session, even if the keying material provided by EAP is 
cached. A cached key persists after the authentication 
exchange has completed. For the AAA/EAP server, key caching 
can happen when state is kept on the server. For the NAS or 
client, key caching can happen when the NAS or client does not 
destroy keying material immediately following the derivation of 
session keys. 


Session keys MUST NOT be dependent on one another. Multiple 
session keys may be derived from a higher-level shared secret 
as long as a one-time value, usually called a nonce, is used to 
ensure that each session key is fresh. The mechanism used to 
generate session keys MUST ensure that the disclosure of one 
session key does not aid the attacker in discovering any other 
session keys. 


Limit key scope 


Following the principle of least privilege, parties MUST NOT 
have access to keying material that is not needed to perform 
their role. A party has access to a particular key if it has 
access to all of the secret information needed to derive it. 


Any protocol that is used to establish session keys MUST 
specify the scope for session keys, clearly identifying the 
parties to whom the session key is available. 


Replay detection mechanism 


The AAA key management protocol exchanges MUST be replay 
protected, including AAA, EAP, and Secure Association Protocol 
exchanges. Replay protection allows a protocol message 
recipient to discard any message that was recorded during a 
previous legitimate dialogue and presented as though it 
belonged to the current dialogue. 


Authenticate all parties 
Each party in the AAA key management protocol MUST be 
authenticated to the other parties with whom they communicate. 


Authentication mechanisms MUST maintain the confidentiality of 
any secret values used in the authentication process. 
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When a secure association protocol is used to establish session 
keys, the parties involved in the secure association protocol 
MUST identify themselves using identities that are meaningful 
in the lower-layer protocol environment that will employ the 
session keys. In this situation, the authenticator and peer 
may be known by different identifiers in the AAA protocol 
environment and the lower-layer protocol environment, making 
authorization decisions difficult without a clear key scope. 
If the lower-layer identifier of the peer will be used to make 
authorization decisions, then the pair of identifiers 
associated with the peer MUST be authorized by the 
authenticator and/or the AAA server. 


AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], 
provide a mechanism for the identification of AAA clients; 
since the EAP authenticator and AAA client are always co- 
resident, this mechanism is applicable to the identification of 
EAP authenticators. 


When multiple base stations and a "controller" (such as a WLAN 
switch) comprise a single EAP authenticator, the "base station 
identity" is not relevant; the EAP method conversation takes 
place between the EAP peer and the EAP server. Also, many base 
stations can share the same authenticator identity. The 
authenticator identity is important in the AAA protocol 
exchange and the secure association protocol conversation. 


Authentication mechanisms MUST NOT employ plaintext passwords. 
Passwords may be used provided that they are not sent to 
another party without confidentiality protection. 


Peer and authenticator authorization 


Peer and authenticator authorization MUST be performed. These 
entities MUST demonstrate possession of the appropriate keying 
material, without disclosing it. Authorization is REQUIRED 
whenever a peer associates with a new authenticator. The 
authorization checking prevents an elevation of privilege 
attack, and it ensures that an unauthorized authenticator is 
detected. 


Authorizations SHOULD be synchronized between the peer, NAS, 
and backend authentication server. Once the AAA key management 
protocol exchanges are complete, all of these parties should 
hold a common view of the authorizations associated with the 
other parties. 
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In addition to authenticating all parties, key management 
protocols need to demonstrate that the parties are authorized 
to possess keying material. Note that proof of possession of 
keying material does not necessarily prove authorization to 
hold that keying material. For example, within an IEEE 
802.111, the 4-way handshake demonstrates that both the peer 
and authenticator possess the same EAP keying material. 
However, by itself, this possession proof does not demonstrate 
that the authenticator was authorized by the backend 
authentication server to possess that keying material. As 
noted in RFC 3579 in Section 4.3.7, where AAA proxies are 
present, it is possible for one authenticator to impersonate 
another, unless each link in the AAA chain implements checks 
against impersonation. Even with these checks in place, an 
authenticator may still claim different identities to the peer 
and the backend authentication server. As described in RFC 
3748 in Section 7.15, channel binding is required to enable the 
peer to verify that the authenticator claim of identity is both 
consistent and correct. 


Keying material confidentiality and integrity 


While preserving algorithm independence, confidentiality and 
integrity of all keying material MUST be maintained. 


Confirm ciphersuite selection 


The selection of the "best" ciphersuite SHOULD be securely 
confirmed. The mechanism SHOULD detect attempted roll-back 
attacks. 


Uniquely named keys 


AAA key management proposals require a robust key naming 
scheme, particularly where key caching is supported. The key 
name provides a way to refer to a key in a protocol so that it 
is clear to all parties which key is being referenced. Objects 
that cannot be named cannot be managed. All keys MUST be 
uniquely named, and the key name MUST NOT directly or 
indirectly disclose the keying material. If the key name is 
not based on the keying material, then one can be sure that it 
cannot be used to assist in a search for the key value. 


Prevent the Domino effect 
Compromise of a single peer MUST NOT compromise keying material 


held by any other peer within the system, including session 
keys and long-term keys. Likewise, compromise of a single 
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authenticator MUST NOT compromise keying material held by any 
other authenticator within the system. In the context of a key 
hierarchy, this means that the compromise of one node in the 
key hierarchy must not disclose the information necessary to 
compromise other branches in the key hierarchy. Obviously, the 
compromise of the root of the key hierarchy will compromise all 
of the keys; however, a compromise in one branch MUST NOT 
result in the compromise of other branches. There are many 
implications of this requirement; however, two implications 
deserve highlighting. First, the scope of the keying material 
must be defined and understood by all parties that communicate 
with a party that holds that keying material. Second, a party 
that holds keying material in a key hierarchy must not share 
that keying material with parties that are associated with 
other branches in the key hierarchy. 


Group keys are an obvious exception. Since all members of the 
group have a copy of the same key, compromise of any one of the 
group members will result in the disclosure of the group key. 


Bind key to its context 


Keying material MUST be bound to the appropriate context. The 
context includes the following. 


o The manner in which the keying material is expected to be 
used. 


o The other parties that are expected to have access to the 
keying material. 


o The expected lifetime of the keying material. Lifetime 
of a child key SHOULD NOT be greater than the lifetime of 
its parent in the key hierarchy. 


Any party with legitimate access to keying material can 
determine its context. In addition, the protocol MUST ensure 
that all parties with legitimate access to keying material have 
the same context for the keying material. This requires that 
the parties are properly identified and authenticated, so that 
all of the parties that have access to the keying material can 
be determined. 
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The context will include the peer and NAS identities in more 
than one form. One (or more) name form is needed to identify 
these parties in the authentication exchange and the AAA 
protocol. Another name form may be needed to identify these 
parties within the lower layer that will employ the session 
key. 


4. AAA Key Management Recommendations 


Acceptable solutions SHOULD meet all of these requirements. 


Confidentiality of identity 


In many environments, it is important to provide 
confidentiality protection for identities. However, this is 
not important in other environments. For this reason, EAP 
methods are encouraged to provide a mechanism for identity 
protection of EAP peers, but such protection is not a 
requirement. 


Authorization restriction 


If peer authorization is restricted, then the peer SHOULD be 
made aware of the restriction. Otherwise, the peer may 
inadvertently attempt to circumvent the restriction. For 
example, authorization restrictions in an IEEE 802.11 
environment include: 


o Key lifetimes, where the keying material can only be used 
for a certain period of time; 


o SSID restrictions, where the keying material can only be 
used with a specific IEEE 802.11 SSID; 


o Called-Station-ID restrictions, where the keying material 
can only be used with a single IEEE 802.11 BSSID; and 


o Calling-Station-ID restrictions, where the keying 
material can only be used with a single peer IEEE 802 MAC 
address. 
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Security Considerations 


This document provides architectural guidance to designers of AAA key 
management protocols. The guidance is also useful to designers of 
systems and solutions that include AAA key management protocols. 


In some deployment scenarios, more than one party in the AAA key 
management protocol can reside on the same host. For example, the 
EAP authenticator and AAA client are expected to reside on the same 
entity. Colocation enables a single unique authenticator identity to 
be sent by the authenticator to the AAA server as well as by the 
authenticator to the EAP peer. Use of the same identity in both 
conversations enables the peer and AAA server to confirm that the 
authenticator is consistent in its identification, avoiding potential 
impersonation attacks. If the authenticator and AAA client are not 
colocated, then the authenticator and AAA client identities will 
differ, and the key scope will not be synchronized between the EAP 
peer, authenticator, and server. Lack of key scope synchronization 
enables a number of security vulnerabilities, including 
impersonation. For this reason, a design needs to include mechanisms 
to ensure that the key scope and key naming are unambiguous. 


The AAA server is a trusted entity. When keying material is present 
at all, it establishes keying material with the peer and distributes 
keying material to the authenticator using the AAA protocol. It is 
trusted to only distribute keying material to the authenticator that 
was established with the peer, and it is trusted to provide that 


keying material to no other parties. In many systems, keying 
material established by the EAP peer and EAP server are combined with 
publicly available data to derive other keys. The AAA server is 


trusted to refrain from deriving these same keys even though it has 
access to the secret values that are needed to do so. 


The authenticator is also a trusted party. The authenticator is 
trusted not to distribute keying material provided by the AAA server 
to any other parties. If the authenticator uses a key derivation 
function to derive additional keying material, the authenticator is 
trusted to distribute the derived keying material only to the 
appropriate party that is known to the peer, and no other party. 
When this approach is used, care must be taken to ensure that the 
resulting key management system meets all of the principles in this 
document, confirming that keys used to protect data are to be known 
only by the peer and authenticator. 


EAP is used to authenticate the peer to the AAA/EAP server. 

Following successful authentication, the AAA/EAP server authorizes 
the peer. In many situations, this is accomplished by sending keying 
material to the authenticator and the peer in separate protocol 
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messages. The authenticator is not directly authenticated to the 
peer. Rather, the peer determines that the authenticator has been 
authorized by the AAA/EAP server by confirming that the authenticator 
has the same AAA/EAP server-provided keying material. In some 
systems, explicit authenticator and peer mutual authentication is 
possible. This is desirable since it greatly improves 
accountability. 


When MIB modules are developed for AAA protocols or EAP methods, 
these MIB modules might include managed objects for keying material. 
The existence of managed objects associated with keying material 
offers an additional avenue for key compromise if these objects 
include the keying material itself. Therefore, these MIB modules 
MUST NOT include objects for private keys or symmetric keys. 

However, these MIB modules MAY include management objects that expose 
names and context associated with keys, and they MAY provide a means 
to delete keys. 
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Appendix: AAA Key Management History 


Protocols for Authentication, Authorization, and Accounting (AAA) 
were originally developed to support deployments of Network Access 
Servers (NASes). In the ARPAnet, the Terminal Access Controller 
(TAC) provided a means for "dumb terminals" to access the network, 
and the TACACS [RFC0927] [RFC1492] AAA protocol was designed by BBN 
under contract to the Defense Data Network Program Management Office 
(DDN PMO) for this environment. [RFC1492] documents a later version 
of TACACS, not the original version that was widely deployed in 
ARPAnet and MILNET [DDNN39.2]. 


Later, additional AAA protocols were developed to support deployments 
of NASes providing access to the Internet via PPP [RFC1661]. In 
deployments supporting more than a modest number of users, it became 
impractical for each NAS to contain its own list of users and 
associated credentials. As a result, additional AAA protocols were 
developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These 
protocols enabled a central AAA server to authenticate users 
requesting network access, as well as providing authorization and 
accounting. 


While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP 
[RFC1661] authentication, the limitations of these authentication 
mechanisms became apparent. For example, both PAP and CHAP are 
unilateral authentication schemes supporting only authentication of 
the PPP peer to the NAS. Since PAP is a cleartext password scheme, 
it is vulnerable to snooping by an attacker with access to the 


conversation between the PPP peer and NAS. In addition, the use of 
PAP creates vulnerabilities within RADIUS as described in Section 4.3 
of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a 


challenge-response scheme based on MD5, offers better security than 
cleartext passwords, it does not provide for mutual authentication, 
and CHAP is vulnerable to dictionary attack. 


With the addition of the Encryption Control Protocol (ECP) to PPP 
[RFC1968] as well as the definition of PPP ciphersuites in [RFC2419], 
[RFC2420], and [RFC3078], the need arose to provide keying material 
for use with link layer ciphersuites. As with user authentication, 
provisioning of static keys on each NAS did not scale well. 


Additional vendor-specific PPP authentication protocols such as 
MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide 
mutual authentication as well as key derivation [RFC3079] for use 
with negotiated ciphersuites, and they were subsequently adapted for 
use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were 
subsequently found in these new mechanisms [SM1] [SM2]. 
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Even though PPP provided for negotiation of authentication 
algorithms, addressing the vulnerabilities found in authentication 
mechanisms still proved painful, since new code needed to be deployed 
on PPP peers as well as on the AAA server. In order to enable more 
rapid deployment of new authentication mechanisms, as well as fixes 
for vulnerabilities found in existing methods, the Extensible 
Authentication Protocol (EAP) [RFC3748] was developed, along with 
support for centralized authentication via RADIUS/EAP [RFC3579]. 


By enabling "pass through" authentication on the NAS, EAP enabled 
deployment of new authentication methods or updates to existing 
methods by revising code only on the EAP peer and AAA server. The 
initial authentication mechanisms defined in [RFC2284] (MD5- 
Challenge, One-Time Password (OTP), and Generic Token Card (GTC) ) 
only supported unilateral authentication, and these mechanisms do not 
support key derivation. Subsequent authentication methods such as 
EAP-TLS [RFC2716] supported mutual authentication and key derivation. 


In order to support the provisioning of dynamic keying material for 
link layer ciphersuites in an environment supporting centralized 
authentication, a mechanism was needed for the transport of keying 
material between the AAA server and NAS. Vendor-specific RADIUS 
attributes were developed for this purpose [RFC2548]. 

Vulnerabilities were subsequently found in the key wrap technique, as 
described in Section 4.3 of [RFC3579]. 


In theory, public key authentication mechanisms such as EAP-TLS are 
capable of supporting mutual authentication and key derivation 
between the EAP peer and NAS without requiring AAA key distribution. 
However, in practice, such pure two-party schemes are rarely 
deployed. Operation of a centralized AAA server significantly 
reduces the effort required to deploy certificates to NASes, and even 
though an AAA server may not be required for key derivation and 
possibly authentication, its participation is required for service 
authorization and accounting. 


"Pass-through" authentication and AAA key distribution has retained 
popularity even in the face of rapid improvements in processor and 
memory capabilities. In addition to producing NAS devices of 
increased capability for enterprise and carrier customers, 
implementers have also produced low-cost/high-volume NAS devices such 
as 802.11 Access Points, causing the resources available on an 
average NAS to increase more slowly than Moore’s law. Despite 
widespread support for certificate handling and sophisticated key 
derivation mechanisms such as IKEvl [RFC2409] within host operating 
systems, these security capabilities are rarely deployed on low-end 
NASes and clients. 
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Even on more capable NASes, such as VPN servers, centralized 
authentication and AAA key management has proven popular. For 
example, one of the major limitations of IKEvl [RFC2409] was the lack 
of integration with EAP and AAA, requiring proprietary extensions to 
enable use of IPsec VPNs by organizations deploying password or 
authentication tokens. These limitations were addressed in IKEv2 
[RFC4306], which while handling key derivation solely between the VPN 
client and server, supports EAP methods for user authentication. In 
order to enable cryptographic binding of EAP user authentication to 
keys derived within the IKEv2 exchange, the transport of EAP-derived 
keys within AAA is required where the selected EAP method supports 
key derivation. 
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